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PREFACE 

GROUND OPERATIONS AEROSPACE LANGUAGE- (GOAL) 


GOAL OVERVIEW 


/'/'inis Overview Document relates the history that led to the development 
>bf the GOAL Language and provic.3S a summary of the features and capabilities 
Of GOAL. ^ j 


OTHER DOCUMENTS TO BE DEVELOPED ARE : a j 

c T 'v' 1 

A GOAL Text BookT tc be used in conjunction with instruction. It will be 
f uncti onal ly onja ni zed to allow an instructor to covec similar statements 
together. , )> > 

A GOAL Reference Manual to facilitate quick access to desired statements. 
It will be alphabetically arranged. 

A GOAL Self-Instruction Manual for individuals desiring to learn GOAL 
rtitnouc additional assistance. This manual will probably follow a "building 
block" approach. 


Prepared for: Director of Center Planning 

and Future Programs 


By: Checkout Automation and 

Programming Office 
Launch Vehicle Operations 
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I. HISTORICAL REVIEW 

The initiative to produce a star.dare test language for the Space Shuttle 
emerged from the experiences gained in test automation during the Saturn/Apollo 
program. Design of the Saturn launch vehicle and its associated ground support 
equipment was such that most commands could be issued by, and most vehicle and 
ground support status data, could be sensed by the ground support computer com- 
plex. Consequently, a high level potential for automation existed in this basic 
design. Initially, the applications program (test programs) written for execu- 
tion in the ground computer complex were almost entirely for loading and verify- 
ing the onboard guidance and navigation computer, for checkout of the control 
system, and for checkout of the emergency detection system. Other systems were 
initially cnecked out manually. 

For these early automated packages, the typical user-programmer communica- 
tions gap was experienced firsthand as test personnel attempted to comprehend 
the programmer's interpretation of the test requirements, lenerally, changes 
were difficult to implement and to understand. Full control over the test came 
only after much actual experience. Even then the details of some operations 
were obscurely embedded in the test packages so that the test engineers had 
difficulties in comprehending the subtleties of the programmer's logic. At 
the time when automatic checkout could have eased the mounting strain associated 
with the pressing schedule, the lack of a common language to communicate require- 
ments and to describe the computer programs further burdened the launch team. 
Problems arose from the lack of concise uniform test notations that could be 
readily understood by personnel of all the different engineering elements. 

During the Saturn IB launch period, a basic set of coded operators, suit- 
able for applications programing, was added to the Ground Computer Operating 
System. This source language was entitled ATOLL for Acceptance Test or Launch 
Language and was conceived and implemented by Marshall Space Flight Center. In 
the early application of this system, it was learned that the success of the 
computer language could be strongly dependent upon its method of implementation 
through the language processor and its execution through the operating system 
(real time executive). The first ATOLL capability employed an on-line trans- 
lator, which in the Saturn Ground Computer System, was operationally inefficient. 
Changes were made to correct the disadvantages, and a much more efficient sys- 
tem was available at the outset of the Saturn V program. Nevertheless, pre- 
judices against test automation lingered for several years until the test 
engineers were convinced that automation would prove to be a useful and respons- 
ive tool. Now the language has evolved to the point where most vehicle disci- 
plines use the lanp’^ge extensively for automatic test procedures. 

For Saturn/Apollo NASA was in the same category for language development 
as most of the other groups who develop test languages within industry or 
Government. That is, the language was developed only after the equipment and 
applications were firmly established and was among the last items to be imple- 
mented. Under this circumstance, the language was subject to criticism as 
another new, unfamiliar, troublesome system that complicated the engineer's 
life and added to his list of problems. 
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., e no.-, nave the opportunity to standardize the basic communications among 
cf ground and in-flight testing at a point in the system acquisi- 
c.c’e where it will become a natural part of the program. This will 
>void costly retrofits and difficult ,, unlearning“ exercises at a later time. 

A properly defined engineer orier.tea language will serve as the basic tool 
in insuring commonality for Orbiter/Booster/GSE Test and Ground Operations Pro- 
cedures while inherently providing the capability to: (1) efficiently automate 

manual procedures, (2) readily adapt design procedures for operational use, 

(3) reduce supporting documentation, (4) efficiently cross-train test personnel, 
(5) minimize impacts from changes, and (6), in general, will be a prime contribu- 
tor in support of the rapid turnaround requirements. 

Thus, in July 1970 contracts were awarded to Marti n-i lari etta, Denver Divi- 
sion and M 4 S Computing, Inc , Huntsville to develop requirements for a standard 
test language. From the results of their reports a language requirements docu- 
ment was published by KSC in May 1971. Since July, 1971, a detailed language 
spec- *ication has been under development by a team of NASA software engineers. 

II. DEVELOPMENT OBJECTIVES AND REQUIREMENTS 

The development of GOAL was based upon several objectives, namely, the lan- 
guage: 

a. Requirements must be consistent with and support the design concepts 
and requirements of the Space Shuttle. 

b. Will not be constrained by specific test equipment. 

c. Will allow the same procedure to be used for both manual and automatic 
testing. 

d. Will provide for a flexible monitoring capability. 

e. Will provide the capability for test personnel to communicate with 
mission software. 

Will be easy to use by test-oriented personnel not necessarily skilled 
in programing techniques. 

g. Will be easy to read and will be self-documenting. 

h. Must be compatible with the philosophy of performing concurrent 
testing. 

From the results of years of ground testing experience and an extensive review 
of many existing languages the following language requirements were tabulated: 

English-like Words, Structure, and Punctuation 

The keywords of the test language form the building blocks of the language 
and care should be taken to select words natural to trie Space Shuttle test- 
environment. Abbreviations should generally be avoided and only in cases 
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where the abbreviation has gained universal acceptance will a deviation be 
considered. These Keywords will be ordered in a logical English form. This 
ordering will promote learning and retention while allowing comprehensive 
error checking. The punctuation symbols and their meaning should be consistent 
with general usage. 

Comments 


A comment :s an expression which clarifies a particular statement or functional 
aspect of a group of statements but is not required to technically define the 
procedural actions of the operation. When automated, comments have no effect 
on the operation of the computer performing the assigned tasks. In some appli- 
cations comments provide the added flexibility required to allow the computer 
listing to be the single control document. Therefore, they should be easily 
inserted into the language statements. 

Total Control of the System Under Test 

The language should allow test personnel to specify test point control to the 
lowest level that is available under tue given system configuration. The 
level of access to a Line Replaceable Unit will probably be different in off- 
line test environment than in the operational system configurations. The types 
of signals used in controlling the test or function operations must not be con- 
strained by the standardized test language. For the Space Shuttle System, the 
language must recognize the requirement for discrete events, digital codes, and 
proportional values (digital representation of analog values). 

Data Sampling 

The test language should support data gathering consistent with system con- 
straints and ground rules. The ability to exercise control over the system 
under test and the ability to measure parameters and status of ;he test item 
are the foundations for testing. Sampling rates should be by a system limit 
and not a language limit. It is possible, after the system constraints have 
been defined, to incorporate the constraints into a language processor which 
will alert the user if his procedure conflicts with system constraints. As 
with control, data samples may be discrete events (ON/OFF), digital codes 
(LRU address), or proportional values (0-100%) . 

Data Ccmparison 

Data comparison is the next basic level above the ability to control test items 
and the ability to acquire the data from the test article. The comparison may 
take many forms (test versus predicted, per cent change from last value, 
deviation during time interval) and the results may be saved for use later 
or may insnedlately effect a change In the processing sequence. The data 
comparison capability should include arithmetic and Ooolean terms in a form 
familiar to the test environment. 

Time Controlled Events 


The extensive use of time factors in sequencing and testing Is a salient 
feature of test and ground operation procedures. During launch preparations, 
test and functional operations are often controlled by a specific time relative 
to liftoff (COUNTDOWN CLOCK). Other functions are based on given time of day; 
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e.g., usually referenced to Greenwich Mean Time. Mission elapse time may be 
used for inflight test and operations. Many of the system sequences must be 
performed in a close time-controlled sequence relative to an occurrence of an 
event within the vehicle. There are also those indicators tnat must be checked 
at a periodic rate. The comprehensive use of time in testing warrants major 
consideration in selecting the proper keywords to be used in a test language. 

Monitoring the System Under Test 

Recognizing that detailed checkout philosophies ha’ e not been defined for 
future vehicles, an increased dependence upon monitoring is an established 
trend in the space and airlines industries. Though most of the existing space 
system checkout facilities include monitoring capabilities, most of the auto- 
mated test languages seem to exclude this capability. Realizing that inter- 
action with the real time hardware/software system could dictate some adjust- 
ments to a predefined test language, the basic language should be able to 
define items to be monitored; e.g., conditioned by t’roe (start/stop and samp- 
ling interval). Thp general capabilities of the language should also be avail- 
able for specifying monitoring packages. 

Information Presentation and Recording 

In the automation of test requirements, the manner in which the data is 
presented to the test evaulator can significantly influence the effort re- 
quired in deducing the proper action to be taken or determining whether or not 
all aspects of the test were completed satisfactorily. The ability to record 
or save selected data, usually correlated with time, is also an operation that 
is frequently performed throughout system testing and must be supported by the 
test language. 

Console Interaction 

At times during a test, an anomaly may appear that justifies suspending acti- 
vity until the system status and integrity can be confirmed. The decision may 
he just to resume operating steps, or rerun certain steps, or to deviate in 
some way by changing test parameters. The basic language requirements to be 
derived from this situation are: (a) the language must be able to suspend 
execution until requested to continue, and (b) the language must accommodate 
the need to change test parameters from a console for certain predefined 
parameters. This feature is also dependent upon the operational hardware/ 
software system and refinements to the language may result fro® later system 
definition. 

Data Manipulation 

Data manipulation is considered to encompass numeric formulas, relational 
formulas, and computer associated assignment statements. Generally, the 
languages that provide arithmetic capabilities provide these capabilities In 
a formula type statement (e.g., FORTRAN type statement). This 1$ a reasonably 
natural and compact way to describe the required calculations. The relational 
formulas are of the comparison type usually expressed In a form of 'EQUAL TO' 
or 'NOT EQUAL TO'. For automatic testing, a closely related requirement 
exists, which is the moving of data items between storage cells. 
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’ ..puter-to -Computer Communications 

It appears that the Space Shuttle will have inter-computer communication in 
f orm. It could De between the central computers, between a central com- 
puter and an engine computer, or between a central computer and an off-vehicle 
computer (ground system or space station system). The test language will 
provide this capability in a manner that will ensure two-way communication 
between digital devices. This will then include the capability to transmit 
and (eceive data from some of the mere complex data bus interface units. 

. nco^poration of Packages Written in Other Languages 

The need to specify certain functions in assembly language is not expected to 
disappear entirely. It complicates a language considerably to include every 
capability necessary to handle highly exceptional requirements. However, to 
ensure that exceptional requirements can be fulfilled, it is necessary to have 
some capability to incorporate assembly language programming consistent with 
the design intent of the language. This feature will probably be used only 
by the soDhisticated test programmer and under a higher level of control and 
validation than required for packages written in the standard test language. 

This requirement recognizes that other languages, assembly level or high order, 
may be needed and the standard test language must support this concept. 

Test Sequence Designation 

A desired test sequence may be stated in several ways. A test procedure usually 
contains many functional elements. These functional elements are comprised of 
a varyinq number of individual operating steps (statements). If the functional 
element must be repeated a number of times, then it may be come a subprocedure 
and referenced by the main procedure, or the steps of the elements nay be in- 
serted the proper number of times, or direction may be given to repeat the 
required steps the appropriate number of times. This looping type capability 
is even more important when the procedure is automated because it often has 
a direct impact on storage allocations required for the procedure. This 
requirement includes the need for directing the sequence based on the condi- 
tion of test Indicators. 

Identification of language Packages and Components 

This includes the obvious need of the ability to reference a specific test 
procedure-for use during testing. For incorporating changes, and for configur- 
ation control . Often procedures must reference other procedures. Individual 
statements within the procedure have the same need; therefore, the language will 
rrevide for labeling of separate packages as well as Individual statements. 

Data Bank Requirement 

The data bank concept Is the feature of the language that allows the language 
to be Independent of the test equipment. It Is basically a cross reference 
taMe Chat relates the eng1u*?ring terminology of a test point to the test 
equipment parameters requiret to a.'cess the test point. For example: the 
procedure might read APPLY BOOSTER MEASURING POWER. The data bank would take 
BOOSTER MEASURING POWER and provide the necessary data for the automatic test 
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c-cuor^rt such as data bus number, interface unit address, line replaceable 
unit designation, and other system related values necessary to locate the test 
point a no to accomplish the desired results. For the Space Shuttle, there will 
probaol;. oe a centrally defined and controlled list of test points similar to 
Apollo documents; e.g., the Saturn V Discrete Running List, Saturn V IP&CL, and 
ACE-S/C Programming Requirements Process Specification Parameter List. Such a 
document for the Space Shuttle would furnish much of the information required in 
the data bank. This is the final link between the language and the test system. 
It also allows procedures to be written Independent of the test system and in. 
advance of the final configuration. 

Table Definition 


Special attention should be given to the definition and use of tables. They 
should prove to be a significant aid in test preparation. The flexibility and 
usefulness of table operations warrants the inclusion of this capability even 
though it might appear more complex than desired. Tables are currently being 
used in Saturn checkout procedures and have become an integral part of daily 
operations and major tests. Generally, they support such functions as system 
statjs checks, switch scans, and performance monitoring. 

Data Types 


Investigation of the Space Shuttle test and checkout applications and previous 
efforts at the definition of test languages leads to the conclusion that the 
following constant and data types are required in the new language. 

(1) Constants 


Writer Aids 


( 2 ) 


(a) Integer 

(b) Fixed Point 

(c) Boolean 

(d) Text 

(e) Binary (Octal or Hexadecimal) 
Data Variables 


Integer 

Fixed 

Boolean 

Text 

Time 


It appears consistent throughout aviation and space vehicle checkout procedures 
that the writing task is a relatively small portion of the overall procedure 
cycle. Tne number of people using, reading, validating, or changing procedures 
car sometimes become rather large. Therefore, while primary consideration must 
be given to the larger group, the test procedures writer Is certainly a vital 
link in the cycle anu should be afforded the capability required to insure 
maximum economy without compromising the primary language objectives. The 
requirement includes such standard concept as replacing the name of one item 
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with another, macro features, and subrouting capabilities. Portions of other 
language requirements also may be implemented in a manner which facilitates 
procedure writing. The final selection must be constrained by the fact that 
the use 1 ' is ill -served by a language which allows him to conveniently describe 
an erroneous procedure. 

Reaction to System Changes 

Test and checkout requirements include the basic needs of being able to respond 
to. such general system indicators as 'start processing,' 'terminate processing,' 
and 'suspend processing.' The command could have been originated by a manual 
entry, another procedure, or an internally-generated command due to detection 
of a serious anomaly. Although che Space Shuttle does not appear to be using 
system interrupts, the language should be able to accommodate interrupts for 
component tyoe testing andto preclude a language impact if the Space Shuttle 
or Space Station implements interrupts at a later time. 

Language Character Set 

To promote general applicability of the language to as many test applications 
and test equipment as practical, only characters may be used that are common 
to the USA Standard Code for Information Interchange Code (ASCII) and the 
Extended Binary Code Decimal Interchange Code ( EBCDIC) . These characters are 
as follows: 


(1) 

Capital Letters: A-Z 


(2) 

Numbers: 0-9 


(3) 

Special Characters: + : 

0 


- ! 

blank 


3 •> 



“ ^ 



' > 

# 


• ( 

$ 


. ) 

X 


; / 

& 


III. LANGUAGE SCOPE AND FORMAT 


GOAL, (Ground Operations Aerospace Language) is a test engineer oriented lan- 
guage designed to be used to standardize procedure terminology and as the test 
p»"ogramming language to be used for ground checkout operations in a space vehicle 
launch environment. It encompasses a wide range of testing, including vehicle 
systems and subsystems p ret light c.'ieekout, ground preflight operation such as 
p opellant transfer, support systems verification, ground power control and 
monitoring, etc. Tha language Is compatible with a wide variety of engineering 
design, requiring primarily command/response (analog and digital) to tne systems 
to be tested. It may be used In the checkout of- line replaceable units, both 
on-board preflight, end in the shop. It allows the seme procedure to be used 
> in bo’;b automatic" and manual modes. GOAL permits a high degree of readability 
-and retalnabflity by providing the necessary operators required for testing, • 
expressed In a familiar notation. Therefore, It is easily learned and under- 
stood Jy personnel not necessarily Skilled’ in programming techniques. After 
•much consideration It was decided to standardise the language statements in a 



readable format prior to compilation, rather than require language readability 
dependency on a conversion program. 

Language Components 

There are five distinct components in GOAL. The two primary components ?- he 
PROGRAM and the DATA BANK. 

PROGRAM: 

A program is an ordered group of statements which, when executed by 
a computer, will progress through the predefined test steps, with- 
in the program, there are two types of statements: DECLARATION and 
PROCEDURAL. 

DECLARATION STATEMENTS consist of data, table, or list declarations. 
DECLARATION STATEMENTS must be grouped at the beginning of a GOAL 
program. They are non-executable statements which reserve storage 
and signify data types during program compilation. 

PROCEDURAL STATEMENTS comprise the remainder of the program. These 
are the stateme'ts which will actually be executed by the object 
machine to perform the desired tost operations. PROCEDURAL STATE- 
MENTS are further classified into external action and internal action 
statements. External action statements stimulate action external to 
the program. Internal action statements are used for the more 
"programmer oriented" tasks such as directing program control, tim- 
ing, and sequencing. 

DATA BANK: 

Past experience has revealed the need for implementation of a data 
bank to supply certain declarations, translations from English 
notation to address patterns, calibration data, and other modules 
of common usage requiring centralized control. This concept is 
vital to minimize the. languages dependence on the test equipment. 

While the initial work has aready been started, the complete defi- 
nition of the data bank will be possible only a*ter the necessary 
detailed system Information is available. However, the GOAL 
specification can be used for test procedure definition indepen- 
dently of this work. 

The data bank Is a separate software entity from the program. It 
contains a collection of specify statements. A data bank acts as 
a central file which provides the linkages between the test pro- 
cedure and the system under test. GOAL allows the use of more than 
one data bank for compilation of a program. A data bank is required 
;on>y if the test program Is to access system subroutines or external 
test points. 



Lie three secondary GOAL components a^e tne SUBROUTINE, MACRO, and NON-GOAL. 

A SUBROUTINE is a self contained set of statements which perform 
a specific task. It is defined once within a program or data bank 
and may be executed by an appropriate perform statement. The 
suoroutine organization is the same as a program, with Declaration 
Statements preceding the Procedural Statements. The calling state- 
ment transfers control back to the main program at the next sequen- 
tial step following the call. Subroutines may contain variable 
parameter locations which are specified by the call statement, or 
they may De completely independent of outside (main program) data. 

A MACRO is a method of allowing the test writer to abbreviate 
character strings which must be repeated throughout his program. 

The character strings to be repeated may be in the program, data 
bank, or subroutines. Each MACRO is assigned a language label. 

The writer may call the MACRO in those locations where he wants the 
sequence to appear and the compiler will perform the task for him. 
The end result on the output listing is the same as if each step 
had been individually coded by hand. 

A NON-GOAL component must be contained within a subroutine and that 
subroutine must be within a data bank. NON-GOAL components can be 
used to provide capabilities that are not inherent in the GOAL 
statement repertoire. 

GOAL STATEMENTS 

The general structure of a GOAL statement is the same as a simple impera*”' 
English sentence, with the subject understood to be the computer. The r. m 
requirement for a GOAL statement is a verb; however, most statements also con- 
tain an object to receive the action. An optional phrase may be used to modify 
the action. That Is, tell when, how often, or how long to perform the action. 
Example: 

Optional Phrase Verb Object 

AFTER <GMT> IS 12 HRS 30 MIN, OPEN <INLET SUPPLY VALVE> ; 

GOAL statements are written In free field format. The free format permits the 
writer to position elements on the page, as he desires, for clarity. It has 
greater flexibility since fixed fields can later be legislated If desired. 

All procedural statements may have a statement number which consists of up to 
six numerals preceded by the word STATEMENT, STEP or S. The statement number 
uniquely Identifies a statement for branching and reference purposes. For 
example, SI 4, STATEMENT 651, STEP 3141 could be statement numbers and need 
not occur In any particular order. 

GOAL notation is In terms of the system under test (SUT) and Is the notation of 
the test engineer, A GOAL statement Is designed to accomplish a certain test 
function. Knowledge o* the actual linkage between the computer and SUT is not 
required because it 1$ obtained from the data bank. . 
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L •- CJA3E CAPABILITIES 

Th» GC/-L Procedural statements provide the basic language capabilities. These 
statements have been grouped into six functional areas which are defined as 
f o 1 1 ows : 

External Tesi. Action 


These statements provide interaction with and control of the system under 
test (SUT). Commands or data may be sent to the test equipment external 
to the program and inputs to the program may be acquired. 

Internal Seouence Control 


These statements control the execution sequence of the program statements. 
Ari thmeti c/Logi cal Qperati ons 

These statements provide the mathematical capabilities of GOAL. They con- 
tain the mathematical capability to add* subtract, multiply, divide and 
exponentiate using notation compatible with the current FORTRAN IV system. 

Execution Control 


These statements provide capabilities for concurrent program execution and 
also for serial execution of other programs and subroutines. 

Interrupt Control 

These statements control the action to be taken when an interrupt occurs. 
Table Control 


These statements enable selective processing of table entries. 

V. SUMMARY 

The necessity for a standard test language must be emphasized. Care should be 
exercised in selecting the scope of tasks that a language describes. The 
assertion that 'one language should be used for everything' sounds attractive, 
but ider close examination this approach would defeat the objective for sim- 
plicity and readability. Many languages have been reviewed to determine if 
they would be sufficient to meet the requirements for a ground test and check- 
out language. Many (such as BASIC, CAGE, SPL, etc.) were rejected because of 
the lack of necessary testing capabilities. Others like FORTRAN required too 
many and too complicated statements to perform specified tasks. Test (Ground/ 
Irf light) and ground operations procedures represent a logical subdivision of 
the total task, and the language supporting these areas should be capable of 
defining most of the required activities. While preserving the general read- 
ability such a capability would help minimize the tedious, costly, time- 
consuming traditional Interface between the test engineer and the progranmer. 
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For the Space Shuttle °rogram, we must make maximum u$e of the lessons learned 

through the years of design and launch experience. The very nature of the 

Space Shuttle design and the essence of the operational concept dictate that 
more be accomplished in a shorter period by fewer people than ever before. 
Automation, then, becomes a requirement for operations, not an elective. To 

effectively apply extensive automation, a test language has no suitable alter- 

nate. 
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